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PREFACE 


EFFECTIVE DATE: June 1993 


This reference publication, "NASA Trend Analysis Procedures," is 
a companion document to NMI 8070.3, "Problem Reporting, 

Corrective Action, and Trend Analysis Requirements." It is 
intended to provide uniform guidelines for conducting trend 
analyses for aeronautics and space programs. It is for the use 
of NASA Headquarters and NASA field installations involved in the 
development and operation of these programs. 

Development of essential information on which NASA management can 
base critical risk-management decisions affecting safety and 
mission success is necessary for the continued credibility and 
success of this Nation's aeronautics and space programs. This 
document has been prepared to support this need and should be 
used in conjunction with the NASA 8070 series of directives. 

General questions on this document should be referred to the 
Office of Safety and Mission Assurance (SMA) , Director, Safety 
and Risk Management Division (Code QS) , Washington, DC 20546. 
Questions concerning the application of these guidelines to 
specific programs or projects should be referred to the cognizant 
SRM&QA Director at the NASA field installation. 


L 


Frederick D. Gregory v * V 
Associate Administrator for 
Safety and Mission Assurance 
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CHAPTER 1: INTRODUCTION 


100 PURPOSE 

1. The purpose of trend analysis is to analyze past 
performance to provide information that can be used to 
assess current status and predict future performance. 

2. The purpose of this reference publication is to 
establish a uniform, agencywide mechanism for providing 
NASA management with trend analysis data on which to 
base top-level decisions affecting the safety and 
success of developmental or operational space and 
aeronautical programs/projects and related payloads, 
and institutional support facilities. 

3. This reference publication supplements policies and 
requirements of NMI 8070.3 by providing specific 
guidance for implementing trend analysis to support 
NASA programs. This publication also supplements NASA- 
STD-8070.5, which provides applicable mathematical/ 
statistical techniques. 


101 SCOPE 

These guidelines support the objectives of the NASA Office 
of Safety and Mission Assurance (OSMA) and are applicable to 
all NASA organizational elements that support technology 
research and development (R&D) , operational space 
programs/projects (including payloads), aeronautical 
programs, and all associated institutional support 
facilities . 


102 POLICY 

NASA policy for the performance and reporting of trend 
analysis is contained in NMI 8070.3. This publication 
provides guidance to assure the proper use of trend analysis 
to support Agency operational functions. Nothing in this 
document is intended to restrict innovation or application 
of trend analysis. 


103 DEFINITIONS 

Definitions of terms are provided in the Glossary of Terms, 
Appendix E. 
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CHAPTER 2: GUIDELINES 


200 INTRODUCTION 

1. The major goal of each NASA program management level is 
to achieve operational and research objectives while 
ensuring that all NASA and NASA-sponsored flight, 
orbital, and ground operations are conducted safely and 
with a full understanding of mission risks. 

Achievement of this goal is supported through rigorous 
engineering analyses and assessments. The NASA system 
of trend analysis addresses the institutional 
characteristics and performance of each program as well 
as progress toward improving the program and 
eliminating problems. 

2. Trend analysis is an element of engineering 
investigation that provides continuing review of 
program factors. Trend analysis has two prime 
characteristics: investigation of actual events and 
comparative assessment of multiple events. Trend 
analysis is applied to program characteristics that 
vary in relation to time, sequence, or element 
performance. Trend analysis results are used to 
evaluate the operation of a program and its component 
systems by assessing past performance to establish 
baselines for current and future performance. When a 
valid trend exists, the accuracy of the analysis will 
increase as more time or event data are collected. 

3. Trend analysis also is used to discover and confirm 
correlations between diverse factors. 


201 BASIC GUIDELINES FOR TREND ANALYSIS 

1. Trend analysis is a formal data analysis approach. It 
is not sufficient to simply plot quantitative data and 
superimpose a trend line. Trend analyses should 
measure correlation and goodness-of-f it; use 
normalization techniques; and qualitatively analyze 
results (i.e., present the management and technical 
reasons for the trends) . 

2. Significant trend analyses should include an assessment 
from the cognizant engineer, technician, or analyst. 
When appropriate, trend predictions should be included. 

3. Trend analysis requirements must be included in all 
program planning phases to ensure the capability to 
provide timely analyses of testing or operational 
events. Planning for trend analysis must include 
selective data collection, development of data analysis 
systems, and the means for disseminating results. 
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202 TYPES OF TREND ANALYSIS 

The NASA Trend Analysis Program comprises four interrelated 
elements of trend analysis: performance, problem, 
supportability , and programmatic. Analyses of these types 
can be found throughout the engineering community; however, 
organizing trend analysis into these specific groupings is a 
NASA-unique approach. 


203 PERFORMANCE TREND ANALYSIS 

Performance trend analyses provide a parametric assessment 
of hardware and software operations to forecast anomalies or 
potential problems. Trends are used to identify impending 
failure or performance degradation in hardware /software, 
particularly those that impact safety or mission success. 

Key characteristics or performance parameters (such as 
temperature, pressure, or erosion) are identified and 
evaluated to determine if they are good predictors of 
failure. In some cases, the characteristics are so critical 
to safety or mission success, that real-time performance 
trend analyses should be conducted. 


204 PROBLEM TREND ANALYSIS 

Problem trend analyses examine the frequency of problem 
occurrence, monitor progress in problem resolution, uncover 
recurring problems, and assess the effectiveness of 
recurrence control. A problem trend analysis frequently is 
an early indicator of performance or support problems, 
thereby generating additional analyses in those areas of 
trend analyses. 


205 SUPPORTABILITY TREND ANALYSIS 

Supportability trend analyses assess the effectiveness of 
logistics elements in supporting NASA programs/projects. 
Supportability trend analysis is concerned with the 
recurrence of logistics problems and the effective control 
of these problems. 


206 PROGRAMMATIC TREND ANALYSIS 

Programmatic trend analyses normally focus on institutional 
program-related indicators of safety or mission success. 
Example indicators include critical scheduling resource 
utilization, overtime, operational noncompliances, and 
time/cost. 
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APPENDIX A 


PERFORMANCE TREND ANALYSIS 


A100 INTRODUCTION 

1. This appendix describes performance trend analysis and 
reporting. A consistent approach is established for 
conducting performance trend analysis and reporting the 
results to NASA management. 

2. Performance trend analysis identifies measurable 
parameters that can indicate component or system 
degradation prior to failure. Sampling a parameter's 
values over time (either historical parameter values 
for the same hardware component or values recorded at 
discrete time intervals during a mission) can reveal 
significant trends in performance degradation prior to 
exceeding a redline limit or experiencing a failure. 

3. Performance trend analysis can be used to detect 
certain types of progressive failure mechanisms prior 
to final failure in a system/subsystem/component. 

These failure mechanisms include (but are not limited 
to) : 

a . Wear 

b. Erosion 

c. Under /overtemperature 

d. Under /overpressure 

e. Vibration 

f. Friction 

g. Leakage 

h. Material property change 

i. Calibration drift 

f. Contamination 

g. Electrical resistance change. 


A200 OBJECTIVE 

The primary objective of performance trend analysis is to 
monitor hardware/software operations to forecast anomalies 
or potential problems of a specific system, subsystem, or 
component . 
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A201 APPLICATIONS 


Applications of performance trend analysis include: 

1. Perform prelaunch maintenance on systems, subsystems, 
and components based on early detection of degrading 
parameters to prevent: 

a. Mission failure 

b. Exceedance of Launch Commit Criteria during launch 
countdown, resulting in launch delay or scrub. 

2. Maintain a unit in service based on trend analysis 
surveillance of the degradation trend line, degradation 
characteristics, and redundancy. 

( Note that this application can be used even if a 
measurable unit parameter exceeds the turnaround 
functional test limit or normal removal time limits ) . 

3. Provide data to support an objective mathematical risk 
analysis to yield a probability estimate for predicting 
remaining life, failure, and limit exceedance. 


A3 00 CANDIDATES 

Candidates for performance trend analysis should be based on 
the following primary selection criteria: 

1. Criticality [based on Failure Mode Effects Analysis 
(FMEA) and Critical Items List (CIL) data] 

2. Availability/trendability of data 

3. Problem history and Engineering judgement. 


A3 01 CRITICALITY (Based on FMEA/CIL Data) 

1. Priorities for performance trend analysis should be 
established based on concern (risk, safety, cost, 
availability, or schedule) and the expected benefits. 

2. Where risk is a primary concern. Criticality 1 items 
should be given highest priority followed by 
Criticality 1R and IS items. 


A3 02 AVAILABILITY/TRENDABILITY OF SENSOR DATA 

1. A determination must be made on whether sensors are 

available from which to obtain performance data (i.e., 
instruments in place to sense measurable performance 
changes) . When no sensors exist, the cost and benefits 
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of developing and installing sensors should be 
considered. Common performance parameters that are 
well suited to Performance Trend Analysis include: 

a. Pressure 

b. Temperature 

c. Voltage 

d. Current 

e. Operating elapsed time/cycle (including on/off or 
open/closed cycle) 

f. Flow Rate 

g. Torque/Motion 

h. Given input/required output. 

2. Sensor data should be analyzed to determine: a) the 
relationship to the condition being monitored, and 
b) whether these data are performance trendable. 
Selected parameters should be capable of showing 
performance degradation (with a definable upper and/or 
lower limit) to allow scheduled corrective action 
before failure. Data sampling rates, transmission 
rates, and system/ subsystem/component degradation 
characteristics should be analyzed and compared to 
determine if the data can be trended to effectively 
show performance degradation. 


A3 03 PROBLEM HISTORY 

1. Selection of candidates for trend analysis includes a 
search of problem reporting data bases [e.g., Program 
Compliance, Assurance, and Status System (PCASS) and 
Problem Reporting and Corrective Action (PRACA) System] 
to identify systems, subsystems, or components with a 
high frequency of reported problems. 

2. Problem reporting records are to be reviewed for 
history of maintenance problems and component problems/ 
anomalies. This review should focus on, but not be 
limited to, the following areas: 

a. In-flight/on-orbit anomalies/failures 

b. Launch delays 

c. Ground checkout anomalies/failures 

d. Component removals. 
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A400 DATA SOURCES 


The data sources for performance trend analysis include, but 
are not limited to the following: 

1. Flight/orbital data 

2 . Prelaunch countdown data 

3. Ground test /checkout /turnaround data 

4. Teardown inspection/analysis reports 

5. Acceptance Test Procedure 

6. Failure analyses 

7. Problem reports [including nonconformance, inflight 
anomaly, and unsatisfactory condition reports (UCRs) ] 


A500 CONSIDERATIONS 

The following sections discuss factors that should be 
considered when conducting performance trend analyses. 


A501 INDIRECT PARAMETER INDICATORS 

There may be cases where a direct indicator of component 
performance does not exist; however, performance can be 
tracked through indirect indications (e.g., pressure may be 
an indirect indicator of temperature) . In these cases, a 
mathematical relationship between the parameters, including 
advisory limits, should be developed for trend analysis. 


AS 02 COMPLEMENTARY PERFORMANCE DATA 

Many systems contain complementary or interrelated 
parameters. As a system (or subsystem) changes state, two 
or more parameters may change in a proportional or inverse 
proportional relationship. These complementary parameters 
can be used to verify the trend of a tracked parameter, thus 
providing redundancy and increasing confidence in the trend 
data. 

AS03 TREND LIMITS ADJUSTMENT (Based on Operating History) 

Operating historical performance data gathered for 
performance trend analysis can be used to evaluate operating 
limits when it demonstrates that actual performance 
variability is less than was anticipated when the limits 
were set originally. 
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AS 04 NORMALIZING/CORRECTION FACTORS 


The operating state, output, or load (about /through which a 
system /subsystem/ component fluctuates) often cannot be 
controlled to achieve consistent trend data. Factors such 
as ambient or on-orbit conditions may affect data 
variability from one checkout or orbit to the next. For 
these cases, it may be possible to determine a normalized 
state, output, or load. If the relationship of the actual/ 
normalized operating states is known, the performance trend 
parameter can be corrected upward or downward to reflect a 
normalized state. Using data from the normalized state will 
result in consistent trend data from checkout-to-checkout or 
orbit-to-orbit . 


A505 PERFORMANCE MEASUREMENTS 

Whenever performance data are recorded, an attempt must be 
made to verify the stability and slope of data approaching/ 
departing the recorded data point. Use of a data buffer is 
recommended to evaluate pre-event data in verifying the 
slope of data approaching/departing the recorded data point. 
Additionally, data filtering and persistence counters should 
be used to verify that the data point is not a noise spike. 
(Whenever a performance advisory limit is exceeded, 
complementary data should be recorded to verify sensor 
condition. ) 


A506 DATA SAMPLING RATE 

For digital samples to correctly represent an analog signal, 
the sampling frequency must be at twice the highest 
frequency component of the analog signal. This rule and its 
mathematical proof are the Nyquist Sampling Theorem, and the 
minimum sampling rate is called the Nyquist rate. If the 
sampling rate is too low (undersampling) , the digital 
amplitude values would represent a low frequency alias as 
well as the original analog signal. 


A507 DATA SAMPLING RESOLUTION 

Analog signals vary infinitely amplitude and frequency. An 
analog-to-digital (A/D) converter cannot perfectly replicate 
an analog signal. At each sampling instant, there is a 
small but finite difference between the analog signal and 
the closest available digital value. This difference is 
referred to as quantization error, which introduces noise 
(known as quantization noise) to the sampled signal. The 
higher the resolution of the A/D converter, the lower the 
quantization error and noise. 
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A508 COMPRESSION-EFFECT ON RESOLUTION 


There are numerous methods to compress data for both storage 
and transmission. These methods can produce either actual 
loss of resolution or problems in data analysis unless there 
is compensation for compression effects. 


A509 DATA/SYSTEM STABILITY 

Data/ system stability must be considered in determining the 
amount of data required to accurately reproduce the desired 
trend. Reduced stability in sampled data requires increased 
sampling rates/resolution. 


A510 CALIBRATION 

To ensure validity, calibration limits and intervals must be 
reviewed to determine system capabilities to produce 
trendable data. Resolution requirements for trendable data 
may exceed those required for normal system monitoring; 
therefore, trend analysis requirements may drive calibration 
limits and intervals. 


A600 PROCEDURES 

The basic steps (see the flow process in Figure A-l) in 

performance trend analysis are: 

1. Analyze hardware/software systems to identify items 
that could lead to a critical or costly failure. 

2 . Prepare a list of these items as candidates for 
performance trend analysis. (Candidate selection 
criteria are addressed in Section 300 of this 
appendix. ) 

3 . Select the items to be analyzed from the list of 
possible candidates. 

4. Determine the parameters to be used in judging whether 
an item's performance is degrading at a rate sufficient 
to warrant management attention. When these parameters 
are critical to safety or mission success, strong 
consideration should be given to performance trend 
analysis . 

5. Determine if measurement data are available for the 
selected performance parameters. A performance 
parameter may be a directly measurable factor, or a 
relationship between two or more parameters (i.e., 
pressure versus time, temperature versus pressure, 
etc.) based on an algorithm. If measurement data are 
not available, determine the feasibility of 
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establishing a system to measure the parameters. If 
feasible, then implement the measurement (s) . 



Performance Trend Analysis Flow Process 
Figure A-l 

6. Establish the performance baseline (acceptance levels 

or bounds) . 

a. Original equipment manufacturer's test data may be 
reviewed to identify failure modes that should be 
monitored and set performance limits for 
performance trend analysis. 

b. Performance trends are identified by tracking the 
measurements obtained during testing and/or actual 
operation, and comparing these data to a defined 
norm or ideal performance baseline (the measurement 
value) . 

c. The following documents should be reviewed to 
determine what values represent acceptable 
performance for each indicator. In most cases, 
acceptable performance should fall within the 
existing operational limits, as stated in these 
documents : 

(1) Operations and Maintenance Requirements and 
Specifications Document (OMRSD) 

(2) Procurement Specifications 


A-7 








(3) 

Flight 

Rules 

(4) 

Launch 

Commit Criteria (LCC) 

(5) 

Design 

Criteria 

(6) 

Shop Specifications. 


7. Determine the measurements necessary to evaluate the 
chosen parameters. The principal elements for 
performance trend analysis include: sensor data, 
time/age/cycle data collected from design and project 
operating elements, together with problem reports in 
associated data bases. 

8. Collect/measure/record the data and conduct a 
performance trend analysis to predict an impending 
failure, or ascertain the aging or degradation of an 
item. If the parameter being trended exceeds the 
historical limits or is below the performance baseline, 
the item could experience a failure. At this point, 
the decision must be made to either retain or replace 
the item. 

9. Report the results using charts, graphs, and 
recommendations . 


A700 REPORTING 
A701 FORMAT 


1. To the extent practical, trend analysis techniques and 
formats should be standardized based on NASA-STD- 
8070.5, "Trend Analysis Techniques." 

2. A trend analysis chart should display the parameters/ 
health indicators, with appropriate analysis parameters 
plotted and annotated. When performance degradation of 
a system, subsystem, or component has been identified, 
the pertinent charts (or reports) should include, but 
not be limited to: 


a. Item: 


Name of system/ subsystem/component 


b. Part No. : 


Manufacturing/vendor part number or 
end item control number 


c. Serial Number: Identification number of the 

system/subsystem/part when 
available and applicable 

d. Criticality: Risk category as obtained from 

FMEA/CIL documentation 
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e. Failure Mode: Failure mode, as obtained from 

FMEA, that is monitored for 
performance degradation 

f. Failure Effect: Results of failure as obtained from 

FMEA/CIL 

g. Assessment and 
Action Required: 

Discussion of what corrective 
action, if any, is required. For 
example, is the 
system/ subsystem/component 
approaching a catastrophic failure? 
Does the item need to be replaced 
or adjusted immediately? 


A702 FREQUENCY 

1. The data analyses, trend charts, and reports should be 
made available to program/project management via 
regular and special reports. 

2. Routine reporting requirements should be established by 
program/project management. Once established, the 
trend reports should be updated at regular intervals. 
Performance trends should be reported periodically, 
normally by month or mission event. However, trend 
reports may be required more frequently, such as when 
trend data indicate rapid change. Trend reports also 
should be made available to NASA Headquarters, Code QS. 

3. NASA management should be alerted in a timely manner of 
any performance trend analysis results that may impact 
safety. 
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APPENDIX B 


PROBLEM TREND ANALYSIS 


B100 INTRODUCTION 

1. Problem trend analysis is intended to identify 
recurring problems and assess progress in problem 
resolution or recurrence control. This type of 
analysis normally focuses on where the key problems are 
occurring and their frequency. Problem analyses (such 
as Pareto analysis) can be a useful starting point for 
focusing attention and determining where other analyses 
(e.g., performance trend analysis) can be of 
significant benefit. 

2. This appendix presents a problem trend analysis 
approach and common techniques that serve as a baseline 
for NASA problem trend analysis. 


B200 OBJECTIVES 

The objective of the approach is to provide an historical 
overview of problems in an easy-to-understand graphical 
format. The overview should assist in decision-making 
relative to design effectiveness, process, or procedural 
changes over time (and the initiation of corrective action 
to improve trends) . 


B300 CANDIDATES 

Candidate items should be comprehensive screened for 
selection because it is not feasible, meaningful, or cost- 
effective to perform problem trend analysis on all NASA 
items/failure modes. Basic criteria for item selection 
include: problem frequency, criticality, engineering 

judgement, and unique program/project requirements. The 
candidate selection process is shown in Figure B-l, "Problem 
Trend Analysis Selection Process Flowchart." Descriptions 
of the process flow elements are as follows: 

1. Review documentation for trending candidates - 
documentation examples include: 


(a) 

Indentured Parts 

Lists 

(b) 

FMEA/CIL/CIRA 


(c) 

OMRSD 


(d) 

LCC 


(e) 

Hazard Analysis 

(HA) 


ya..gt tffT HLM* 
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(f) NASA Center, prime contractor, or subcontractor 
Problem Reports 

(g) Program/project meetings. 

PROBLEM TRENDING SELECTION PROCESS FLOW CHART 



Figure B-l 


2 . Failed - Search the Center problem report data base 
and/or other data bases to identify failures. 

3 . Discard - Determine whether to monitor the item for 
possible future trend or to delete the item completely. 

4. Monitor - Observe the item until there is justification 
to repeat the screening process. 

5. Delete - Remove item from consideration for trend 
analysis. 

6. Criticality 1/1R - Review failures obtained from 
problem report data base search. 

7. Launch Delay History - Review failures obtained from 
problem report data base search to determine whether 
launch delays were encountered regardless of 
criticality. 

8. Engineering Judgement - Assessment engineers review 
failures and decide whether to trend, discard, or 
monitor based on the technical aspects or failure 
history of an item. 
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9. Failures > X - Review failure frequency over time to 
determine whether trend analysis is feasible. 
Determine if sufficient failures are available to 
depict effects based on Engineering Change Proposals 
(ECPs) . 

10. Last Occurrence Within t - Consider date of last 
occurrence to decide whether to trend. 

11. Customer Request - Process request for trend analysis 
without the restrictions applied to other trend 
analysis sources. 

12. Selected for Trend Analysis - Implement actual trend 
analysis of selected item. 

13. Monitor or Discard - Customer decides to monitor or 
discontinue item from further consideration for trend 
analysis. 

14. Trend Per Flowchart for Five-Step Trend Analysis 
Approach - The Five-Step Trend Analysis Approach is 
described and illustrated in Section 600 below. 


B400 DATA SOURCE8 

The primary sources for problem trend analysis data are the 
failure or problem reporting and corrective action systems, 
such as PRACA, supported by other data bases as required. 
Unless the trend analysis is uniquely directed toward the 
contractor's internal operation, it is preferred to use the 
problem reports written during and after component-level 
acceptance testing. 


B500 CONSIDERATIONS 

Fundamental areas of consideration that should be included 
in problem trend analyses are as follows: 

1. Level of analysis (system, subsystem, or component) 

2. Engineering judgement 

3. Statistical analysis 

4. Conflict between engineering judgement and statistical 
analysis 

5. Data normalization 

6. Adverse and favorable trends 

7. Multiple failure problem reports. 
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B501 LEVEL OP PROBLEM TREND ANALYSIS 

Trend analysis must consider specific failure modes (with 
knowledge of the failure mechanisra/causes) to effectively 
evaluate a trend and make specific recommendations for 
corrective action. To evaluate the effectiveness of 
corrective actions such as design or process changes, 
problem trend analysis should be performed at the lowest 
system/ subsystem/component level for which problem data are 
available for the failure mode involved. There are two 
methods for evaluating a trend: engineering judgement and 
statistical analysis. 


B502 ENGINEERING JUDGEMENT 

Engineering judgement is the basis for identifying a trend 
and classifying it as adverse or favorable. It applies 
when: 


1. Sample size (quantity of problems and data points) is 
not sufficient for statistical trend analysis. 

2. Failure mode and root cause are well understood. 

3. Corrective action is well understood. 

4. Statistically downward trend levels out above zero, 
with one or more problem reports per year in most of 
the recent years trended (see Figure B-2) . 
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5. Sufficient failure-free tests or inspections have been 
conducted to verify effectiveness of the corrective 
action. 

Where practical, the results of engineering judgement should 
be verified by statistical analysis. 


BS03 STATISTICAL ANALYSIS 

1 statistical analysis of a trend should be based on a 

sample of at least 30 problems; however, a minimum of 5 
problems (with at least 5 years of data or 5 sets of 
mission hardware) could suffice. 

2. If corrective action is required based on a trend 
analysis, the failure mode(s) that constitutes the 
greatest area(s) of concern must be identified for 
trend analysis. 

B504 CONFLICT BETWEEN ENGINEERING JUDGEMENT AND STATISTICAL 
ANALY8I8 

Normally, engineering judgement and statistical analysis 
methods should yield the same trend conclusion (adverse or 
favorable) . However, if there is a conflict in trend 
direction, engineering judgement usually is preferred for 
small sample sizes and statistical analysis for large sample 
sizes. There is no substitute for engineering judgement in 
assessing the importance of a trend. As an example, for 
extr6ni6ly serious conditions, a favorable trend may only 
indicate that a situation is slowly improving where a more 
rapid trend of improvement is required. 


B505 DATA NORMALIZATION 

1. Prior to problem trend analysis, the quantity of 

problem reports per time interval (week, month, year) 
or per set of mission flight hardware must be 
normalized. 1 Examples of normalized data are: 

a. Problems per 10,000 seconds of run time 

b. Problems per 100 tests or inspections 

c. Problems per mission/ flow 

d. Number of firings per year 

e. N umb er of end items delivered per month. 


1 Additional information regarding normalization can be found in 

NASA- STD -8070. 5 , Section 4 . 4 . 9 . 
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Data should be normalized at the lowest possible 
assembly level. For example, turbopumps often are 
shifted from engine-to-engine, and pumps are of the 
Phase I design. Thus, turbine blade cracking or 
bearing wear should not be normalized using Space 
Shuttle Main Engine (SSME) system-level data, but 
rather by the applicable Phase II turbopump design 
data. 


B506 GOODNE88-OF-FIT 

Goodness-of-f it of the trend to the data points is 
determined using the R-square (R 2 ) value. (A thorough 
explanation of R 2 is provided in NASA-STD-8070. 5. ) The 
highest R 2 value should be selected from one of the 
following trend models: 

1. Linear 

2. Exponential 

3. Power (geometric) 

4. Logarithmic (log linear) 

5. Positive parabolic. 


BS07 TREND DIRECTION 

Trend direction should be determined using the sign of the 

R 2 value. 

1. If R 2 is less than the value in the table in NASA-STD- 
8070. 5, pp. 4-31, the trend may be declared level. If 
R 2 is more than the value, it would be declared upward 
or downward, depending on the R 2 value sign (positive 
or negative, respectively) . 

2. Generally, a line is good for fitting upward trends; 
however, downward trends often are better fitted 
(higher R 2 value) using one of the nonlinear models. 

If the R 2 value is not statistically significant, it 
must be inferred that the trend is level or adverse. 
However, engineering judgement still must be applied. 


B508 ADVERSE AND FAVORABLE TRENDS 

The determination of the adverse or favorable nature of a 
trend depends upon the system that is being trended. A 
system that is expected to sustain a certain level of random 
failures would have an adverse trend if the failure rate 
increases or is predicted to exceed the design failure rate. 
A critical system that is maintained and operated to avoid 
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all failures would have an adverse trend if a failure mode 
reoccurs subsequent to the institution of failure recurrence 
control after the first failure. Only a result of "no 
problems reported in that failure mode" would be favorable; 
any upward or level trend would be considered adverse. 


B600 PROCEDURES 

B601 HIERARCHICAL APPROACH AND THE FIVE-STEP METHOD 

1. Figure B-3 shows typical steps used to identify a 

component failure mode for trend analysis. Based on 
the highest frequency of problem reports at each 
hierarchical level, one might select the element (if 
applicable) followed by the system, subsystem, 
component, and finally the failure mode. 

PROBLEM TRENDING 
SERIES FLOW CHART 


ELEMENT 

SYSTEM 

subsystem 

COMPONENT 

FAILURE MODE 

1. 8SME 

2 ET 

3 SRB 

4 3RM 
6 RAY * 

LOADS 

COMBUSTION 

TURBOMACH. 

PNEUMATICS 

PROP VALVES 

HYDRAULICS 

IGNITERS 

HARNESS 

INSTRUMENT 

PLUMBING 

INTERCONNECT 

GIMBAL 

ENGINE 

HPOTP 

BEARINGS 

BALL WEAR 

INNER RACE 
CRACKS 

CONTAMIN 

CHART 

TYPE: 

TREND 

ALL 

PROBLEMS 

TREND 

ALL 

PROBLEMS 

PARETO 

ALL 

FAILURE 

MODES 

TREND 

FAILURE 
MODES OF 
CONCERN 



Figure B-3 


2. There are many valid methods of performing problem 
analysis; the five-step method is the recommended 
approach for achieving consistency throughout NASA 
(Figure B-4) . This should not preclude the use of 
other methods that may be more applicable in particular 
circumstances . 

3. The five-step method of problem trend analysis 
comprises the following activities: 

a. Research appropriate data base(s) and extract data. 
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b. Construct a normalized subsystem-level or 
component-level trend chart. 

c. Construct a Pareto chart of failure modes/causes 
and identify area(s) of concern. 

d. Construct a normalized trend chart for each area of 
concern and failure mode. 

e. Prepare a summary assessment of the problem trend, 
including: 

(1) Suspected failure mode(s) 

(2) Root cause (s) 

(3) Recommended or actual corrective action(s). 

6-STEP TRENDING METHOD 
FLOW CHART 



AND ASSESSMENT FOR A GIVEN 
ITEM AS ADDITIONAL DATA BECOMES 
BAILABLE 

Figure B-4 


B602 STEP 1 : RESEARCH DATA BASE AMD EXTRACT DATA 

Automated data search and manual activities are necessary to 
obtain data for problem trend analysis. Primary 
considerations in Step 1 are as follows: 

l. ground Rules for Data Inclusion/Exclusion . In 

researching the data for trend analysis of a given 
component, the primary data source is usually the 
problem report data base for the cognizant design 
center. A second source of data may be the launch 
center problem report data base for flight component 
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problem reports. In-flight/ on-orbit anomalies are 
available from the cognizant design, launch, and 
operations centers. Ground rules used in excluding 
data should be noted, for example: 

a. Pre-acceptance test problems 

b. Facility/test equipment problems 

c. Nonflight configuration problems 

d. (Space Shuttle only) Solid Rocket Motor (SRM) and 
certain other hardware problems prior to post- 
Mission 51L redesign 

e. (Space Shuttle only) Data from the first post- 
Mission 51L return-to-f light mission for each 
Orbiter . 

2. Data Search . The data search should begin with the 
problem report data bases and include other applicable 
problem reports (e.g., NASA reports, contractor data). 
As a minimum, the data base query should include: 

a. Calendar period or mission numbers 

b . FMEA Code 

c. Line Replaceable Unit (LRU) Part Number 

d. Word search for failed component/ failure mode. 

3. Manual Activities . Manual activities include, but are 
not limited to: 

a. Excluding nonapplicable problems 

b. Reading problem reports to verify correct failure 
modes 

c. Reviewing FMEA for assignment of new criticality 
categories 

d. Obtaining time/cycle data or number of units 
inspected/tested for normalization. 

B603 STEP 2 : CONSTRUCT A SUBSYSTEM OR COMPONENT- LEVEL NORMALIZED 

TREND ANALYSIS CHART 

The chart includes all problems (except those excluded by 
ground rules) on a selected subsystem or component, without 
identification of failure modes. Prior to trend analysis, 
the problem frequency is normalized by run time, cycles, 
sets of mission flight/orbital hardware, inspections, or 
other parameters. Both the raw data (quantity of problems) 
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and normalized data are displayed (Figure B-5) . The trend 
direction (normalized data) may be determined by 
observation, or either a linear trend line or curve may be 
plotted. Trend direction is established by plotting all 
failure modes; a single corrective action is not applicable. 
The trend direction is observed only for information 
relative to overall condition of the subsystem and/or 
component. 
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Figure B-5 

B604 8TEP 3 : CONSTRUCT A PARETO CHART OF FAILURE MODES/CAUSES 

AND IDENTIFY AREA (8) OF CONCERN 

1. The Pareto chart (Figure B-6) shows frequency of all 
observed failure modes/causes and identifies each 
failure mode/cause that is (from an engineering 
viewpoint) an area of concern. If the data base cannot 
sort data by failure mode/cause, it may be necessary to 
read each problem report on a failed component. 
Reviewing problem reports also may be necessary when 
cause codes are available because different engineers 
can assign different failure mode codes to identical 
failures. 

2. As a minimum, the Pareto chart should indicate the 
following for each area of concern failure mode: 

a. Quantity of Criticality 1/1R problem reports by 
failure mode 

b. Percent of all problem reports by failure mode 
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c. Quantity of problems reported by year (or mission) 

d. Problem report closure status (quantity open and 
quantity closed) 

e. Date of last failure. 
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Figure B-6 


B605 STEP 4 : CONSTRUCT A NORMALIZED PROBLEM TREND CHART FOR 

AREA (8) OF CONCERN 

A chart such as Figure B-7 is prepared for each failure mode 
or cause identified as an area of concern. Chart 
preparation should consider data normalization, R 2 values, 
design/process/procedure changes, and engineering judgement. 

1 . Data Normal iiation . It is important to normalize trend 
data whenever possible to eliminate misleading trends. 
Usually, low-cycle fatigue problems are normalized by 
exposure cycles (quantity of tests) , and high-cycle 

fatigue problems by operating time of exposure. In the 
event that problem reporting in a given area is reduced 
or discontinued, consideration should be given to 
normalizing for the reduced reporting. For example, if 
20 percent of applicable problems during and after the 
acceptance test procedure (ATP) were due to a process 
that is no longer reported, the subsequent trend data 
should be adjusted upward (multiplied) by 1.00/0.80 = 
1.25. 
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CONCERN: BEARING BALL WEAR 



CALENDAR YEAR 

NOHMAi 1 7fc D By hPOI P SFC.ONOS 
STAll S I M A| l I Ni)N SIGNIFICANT TREND 


2 . 


Figure B-7 

R 2 Values . For each trend, only the models for which 
the fitted points have no negative values can be 
candidates for selection. When R 2 values for any of 
the five models (linear, exponential, power, 
logarithmic, or positive parabolic) are approximately 
the same (difference < 0.020), the one that best fits 
the extreme right data point would be selected. 


Desicm/Proceaa/Frocedure Changes . Design, process, or 
procedure changes that could eliminate the failure mode 
should be shown at the appropriate point on the trend 
chart (Figure B-8) . Usually, it is desirable to show 
raw data and normalized data both prior to and after 
the design change on a failure mode trend chart. Only 
the normalized data are trended. It is not recommended 
to show a trend line or curve on the trend chart unless 
the trend is declared statistically increasing or 



4. Engineering Judgement . If the failure mode, root 

cause, and corrective action are well understood and 
the number of subsequent tests (or seconds or 
inspections) without failure is considered sufficient, 
trends with few data points that have ended with zero 
failures may be declared as downward. 


a. The example illustrated in Figure B-8 involves 
quantities of case-to- insulation debonds on the 
Redesigned Solid Rocket Motor (RSRM) based on 
occurrences on successive sets of mission flight 
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hardware. The plotted data indicate process change 
points on RSRM segments. Engineering knowledge of 
the changes plus six clevis end failure-free 
flights after the grit-blasting change indicates a 
statistically verified downward trend. Although 
initially considered downward, the tang end trend 
is not statistically significant and, therefore, is 
identified as an adverse trend. 

REDESIGNED SOLID ROCKET MOTOR 
CONCERN: RSRM INSULATION TO CASE 
DE BONDS 

REPORTED AT K»C. FINAL INSPECTION (? 0 ITS’ DEEP! 



Figure B-8 


b. Figure B-9 is a backup chart useful to show 

location of trended problems (in this case, by 
flight vehicle and RSRM segment) . 


B606 STEP 5 : PREPARE SUMMARY ASSESSMENT OP PROBLEM TREND 

ANALYSI8 VI TH RECOMMENDATIONS 

A sample summary assessment is provided in Figure B-10. The 

following are proposed inputs for a summary assessment: 

1. Data source if other than cognizant Center PRACA data 
base. If applicable, provide ground rules for excluded 
problem reports (refer to Section 602 of this 
appendix) . 

2. Component and failure mode(s) trended, including 
quantity of problem reports. 

3. CIL Code Number. 

4. Failure mode(s) criticality and date of last failure. 
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Figure B-9 


5. Primary failure cause/ subcause. 

6. Design/process/procedure changes, with effectivity. 
Indicate if any data prior to such changes are 
excluded . 

7. Trend direction (increasing, level, or decreasing). 

8. Trend evaluation (adverse, acceptable, or favorable). 

9. Recurrence control action. 

10. If applicable, a statement regarding additional data 
(trend analysis update) needed to evaluate the trend 
direction. 

11. As applicable, recommendations based on engineering 
analysis of the trend and a statement regarding 
additional resources required to correct an adverse 
trend. When the failure mode for the area of concern 
can be characterized by a variable (e.g., dimension, 
load, voltage) , recommend performance trend analysis of 
the variable versus run time, cycles, or inspections. 

An option is to correlate the variable with influence 
parameters (pressure, temperature, and critical 
dimension) . 
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SUMMARY ASSESSMENT (SAMPLE) 


FAILURE MODE; HPOTP - LOSS OF SUPPORT OR POSITION 
THIS FAILURE MODE IS FMEA CRITICALITY 1 
CIL ITEM NUMBER 8400-13 

FAILURE CAUSE A; HPOTP PHA8E II BEARING ANOMALIES 
FAILURE SUBCAUSE #!: 

BEARING BALL WEAR: 

17 UCRS: MOST RECENT FAILURE OCCURRED IN SEPTEMBER 
1980 EXCESSIVE WEAR CAU8ED BY LOW TO NEGATIVE 
COOLANT VHPOfl MARGIN. AT LEAST 10 OF THESE 17 UCRS 
WERE WRITTEN ON PUMP - ENO BEARING #2. THE LATEST 
RECURRENCE CONTROL IS TO LIMIT BEARING OPERATING LIFE 
TO 2588 SECONOS BY DAR* WITH REPLACEMENT OF THE 4 
HPOTP BEARINGS PRIOR TO EACH FLIGHT TREND IS 
ADVER8E (LEVEL). 

RECOMMENDATION: 

ROCKETDYNE. PRATT A WHITNEY AND MSFC DIRECT BEARING 
TESTING SO AS TO IDENTIFY 0E8IGN CHANGES THAT 
WOULD INCREASE BEARING LIFE BY DECREASING BALL WEAR. 
PERFORMANCE TRENDING OF BALL WEAR VS. RUN TIME AND 
CORRELATIONS OF BALL WEAR WITH INFLUENCE PARAMETERS 
SUCH AS INTERNAL CLEARANCE. LOX COOLANT FLOW, ETC. 
SHOULD BE UPDATED 


• OfVIATIONt RfQUffT 


Figure B-10 


B700 REPORTING 
B701 FORMAT 

The format described and illustrated in Step 5 in the 
process (Section 607) should be used in the reporting 
problem trend analysis. 

B702 FREQUENCY 

The frequency of problem trend analysis reporting is 
determined by program needs; as a minimum, an overall 
program/project problem trend analysis should be reported 
monthly. Cyclic programs/projects such as Space Shuttle 
missions also should report problem trend analysis based on 
the cycles. Where programs are comprised of major elements, 
the elements should be reported in addition to the overall 
project reporting requirements. 


B703 REPORTING RESULTS 

Each trend analysis organization should establish a method 
of dissemination that meets their specific requirements. 
When reporting problem trend analysis results in support of 
management decisions, include the following activities: 
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1. Coordinate early trend analysis products (chart 
preparation) with cognizant organizations ( SRM&QA , 
project/prime contractor, and engineering offices) . 

2. Establish a routine periodic hard copy distribution 
(e.g., quarterly, monthly) of current trend charts. 

3. As applicable, maintain a display of selected current 
trend charts. 

4. Provide trend charts for real-time support of mission 
reviews . 

5. Provide immediate distribution of charts identifying 
adverse trends. If an adverse trend impacts hardware 
on a vehicle about to be launched, the most expeditious 
communication technique must be used. 


B704 MAINTAINING PROBLEM TREND ANALYSIS STATU8 

When selection of items for trend analysis is complete, it 
is essential to maintain a status or accounting system. A 
suggested format for this effort is provided in Table B-l, 
"Problem Trend Analysis Program Status." Descriptions of 
column headings are as follows: 

1. Element . Selection criteria for items trended (refer 
to Section 300) . 

2. Planned . Number of deficient hardware items to be 
trended. Some planned items may not be trended because 
of insufficient data points, redesign, etc. The 
quantity in this column is equal to the sum of the next 
three columns. 

3. Currently Trended . Number of items for which at least 
one trend chart exists. 

4. In-Process . Number of items for which trend analysis 
is underway but no trend chart exists. 

5. Inactive . Number of items planned for trend analysis, 
but which are neither trended nor in-process. (This 
category may include items that were trended, but have 
been temporarily discontinued.) 

6. Remarks . Any pertinent explanatory notes. 
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Table B-l 


PROBLEM TRENDING PROGRAM STATUS 


ELEMENT 

PLANNED 

CURRENTLY 

TRENDED 

IN 

PROCESS 

INACTIVE 

REMARKS 

SSME 
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10 
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1 

2 

1 

0 
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1 
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0 
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F - FREQUENCY 
C * CRITICALITY 
E - ENGINEERING 
M - MSFC 

If 
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0 

IS 

0 

0 
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LOW FRBOUIHCY. 

OF aUOaUNTIAt 
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79 

42 

1 

36 
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APPENDIX C 


SOPPORTABILITY TREND ANALYSI8 


C100 INTRODUCTION 

1. This appendix provides a consistent approach for 
conducting supportability trend analysis and reporting 
results to NASA management. 

2. Supportability trend analysis is concerned with the 
assessment of the effectiveness of the logistics 
support system. The common logistics elements include, 
but are not limited to: 

a. Maintenance 

b. Supply support 

c. Support equipment 

d. Facilities management and maintenance 

e. Support personnel and training 

f. Packaging, handling, storage, and transportation 

g. Technical data support 

i. Automated data processing hardware/software support 

j. Logistics engineering support. 


C200 OBJECTIVES 

The primary objectives of supportability trend analysis are: 

1. Monitor the current health of support systems. 

2. Forecast support problems to enable resolution with 
minimum adverse effect. 

3. Determine which support elements can be improved to 
optimize the system availability over its operating 
life. 

4. Measure effects of system reliability and 
maintainability on supportability and identify areas 
for improvement. 

5. Analyze current support systems to estimate future 
requirements. 


V*. A ** MU? i-K’T M* 
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Identify the relationships between support and other 
program/project factors. 


C300 CANDIDATES 

1 . Because elements of supportability trend analysis are 
based on the common elements of logistics support and 
logistics engineering, the candidates for this analysis 
are generally well known. Candidates for trend 
analysis should be selected to provide an accurate 
measurement of the effectiveness of the support 
elements and the reliability/maintainability design 
factors. 

2. Examples of common candidates for supportability trend 
analysis include: 

a. Repair turnaround time (TAT) 

b. Scheduled maintenance activity 

c. Unscheduled maintenance activity 

d. Modifications 

e. Zero balance inventory items 

f. Cannibalization 

g. Technical documents changes 

h. Fill rate 

i. Impending loss of spare/repair capability 

j. Personnel skill adequacy. 

k. Repetitive failures. 

3. Examples of supportability trend analysis candidates 
used to evaluate system reliability/maintainability/ 
availability support characteristics include: 

a. Mean-time-between-failures (MTBF) 

b. Mean-time-to-repair (MTTR) 

c. Mean-time-between-repairs (MTBR) . 

4. Priorities should be established based on the area of 
concern (risk, safety, cost, availability, and 
schedule) and the expected benefits of the trend 
analysis. Where risk criticality is a primary concern, 
Criticality 1 items should be given highest priority 
followed by Criticality 1R/1S items. 
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A prime concern in supportability trend analysis is the 
determination of the extent of analysis and 
identification of the appropriate parameter variation 
that must be measured. Selected parameters must be 
measurable and capable of showing sufficient variation 
to be useful in monitoring the factor under analysis. 

6. A determination must be made if parameters are 
measurable, "sensors'' are available to obtain 
supportability data, and data systems are in place to 
obtain/record the supportability factor. In the 
context of supportability, a sensor is a manual or 
automated method of obtaining and recording data. When 
no sources exist, the cost and benefits of developing 
and installing sensors should be considered. Consider 
automating data recording, storage, and retrieval when 
manually stored data are to be used continually or in a 
large number of analyses. Use of existing data systems 
or labor-saving methods (such as bar coding) offer the 
opportunity to automate data processing at minimum cost 
in manpower/equipment. 

7. The following example illustrates the importance of 
selecting appropriate parameters to measure the 
effectiveness of a support system. A common analysis 
involves the time to repair/refurbish a piece of 
equipment from its turn-in for repair until its 
availability for issue in a ready-for-installation 
(RFI) condition. This is an appropriate way to measure 
the overall turnaround time (TAT) of the entire support 
system established for that equipment. If the goal of 
the analysis is to monitor the performance of a 
particular facilities repair process, the parameter to 
be measured should be the time between receipt at the 
maintenance facility until the item is ready for 
shipping back to the support site. 


C400 DATA SOURCES 

1. There are usually many data sources for analysis of 
supportability factors. Because the data sources 
relate to contractual and fiscal matters, the records 
often are recorded and stored manually. Automated data 
usually are confined to unique accounting systems that 
are not interconnected with other supportability data 
bases. Thus, establishing this analysis requires 
considerable understanding of the logistics elements 
and the supporting administrative systems. 

2. Available data may not be in a form that is readily 
usable. In many cases, contractual requirements may 
complicate the process of obtaining necessary data. 
Processing certain data is so labor-intensive that the 
use of that data is impractical or infeasible. 
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Contract modifications and funds expenditures may be 
necessary to obtain critical data. 

Excellent data sources for supportability trend 
analysis may be found in: 

a. Equipment problem reports 

b. Work authorization documents 

c. Contractual acceptance records 

d. Shipping and receiving reports 

e. Payment records for maintenance 

f. Transportation records 

g. inventory and issue/ turn— in records 

i. Training course attendance records 
j . Technical documentation error reporting 
k. Consumable replenishment records. 

4. Each program/project should recognize the relationship 
between these data sources and the supportability 
factors. Recognizing the relationships should lead to 
an understanding that analysis of supportability data 
is often as important to a program/project as 
performance data. 


C500 CONSIDERATIONS 

There are many factors to be considered for a supportability 
trend analysis, including: 

1. Maintenance operations 

2 . Selection criteria 

3. Line items/ spare parts 

4. Indirect indicators 

5 . Complementary data 

6. Trend limits 

7. Normalization factors 

8. Causes of delayed data 

9. Data accuracy. 
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C501 MAINTENANCE CONCEPT 

Maintenance operations are performed within a three-level 
structure: Organizational, Intermediate, and Depot. Each 
action is assigned to the level at which it can be 
accomplished most effectively. Organizational level 
maintenance may be considered on-line operations, while 
Intermediate and Depot level maintenance may be considered 
off-line maintenance. A system maintenance concept may 
involve any co mb i nation and degree of maintenance levels. 
In many cases, only one or two of the levels are used. 


C502 8Y8TEM/8UB8YSTEM/UNIT SELECTION CRITERIA 

The program/project should prioritize systems, subsystems, 
and LRU/Orbital Replaceable Units (ORU) prior to selecting 
areas for trend analysis reporting. Prioritization should 
consider areas such as functional criticality, cost, failure 
rates, MTTR, maintenance demand rates, and repair TAT. The 
list of selected items should be reviewed and updated as 
required. 


C503 LIMB ITBK8/8PARE PARTS 

Supportability trend analysis commonly analyzes line items, 
which are inventory items that have unique part numbers. 

Some analyses of line items do not consider the quantities 
of the line items; users must consider whether the reference 
to the n umb er of line items includes the quantities of each 
line item involved. Analyses, such as line-items-below- 
minimum-balance are concerned with the status of the line 
items rather than their quantities. 


C504 INDIRECT PARAMETER INDICATORS 

Where a direct indicator of component supportability does 
not exist, supportability may be tracked through an indirect 
indicator. A mathematical relationship between parameters, 
including advisory limits, is developed to translate the 
measured parameter to the analyzed parameter . 


C505 COMPLEMENTARY DATA 

In systems where more than one parameter may be used as a 
direct indicator of supportability, one parameter is 
selected for use. When practical, complementary trend 
analysis of a second parameter may be used to verify a trend 
(redundancy) and increase confidence in the primary 
analysis. 
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C506 TREND LIMIT8 ADJUSTMENT BASED ON OPERATING HISTORY 

As operating history is compiled for each supportability 
indicator, the supportability limits should be evaluated for 
revision if the historical baseline (norm) consistently 
differs from the original. Reestablished limits must be 
consistent with program/project goals. 


C507 NORMALIZING/ CORRECTION FACTORS 

Support operations are subject to variables such as schedule 
delays or funding availability. While it may not be 
possible to control these factors, it is possible to analyze 
the operation by adjusting the measurement of the support 
element to compensate for the variable. If the relationship 
of the actual and normalized operating states is known, the 
supportability trend parameter can be corrected upward or 
downward to reflect a normalized state. Using data from a 
normalized operating state should produce consistent trend 
data from one mission or period to the next. 


C508 DATA DELAY 

Because a large amount of the data used for supportability 
trend analysis is captured in writing or unique data bases, 
the time to review and process the data often precludes 
determination of current program/project status. Trend 
reports should annotate the time factor and provide a clear 
method of estimating current status using the data available 
at the time the report was prepared. 


C509 DATA ACCURACY 

Experience shows that minor inaccuracies can develop in any 
data recording system. The program/project periodically 
should examine the data for accuracy. If errors are found, 
the data still may be useful for trend analysis. Even if 
the absolute values of the data are erroneous, the 
supportability trend analysis of the data may yield useful 
comparative trend information if the errors are caused by 
consistent miscalculations. 


C510 CORRECTIVE ACTION 

The following examples illustrate actions that may be taken 
to correct adverse supportability trends: 

1. Given an unusual demand on spares or maintenance 

capabilities, increase resources to meet increased 
usage. Investigate the cause of the upsurge in demands 
to correct the situation. 
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2 . 


Measure the effects of system reliability and 
maintainability characteristics on support factors. 
For systems that do not meet design supportability, 
increase the level of maintenance/provisioning and 
recommend design modifications to improve life-cycle 
support . 


C600 PROCEDURES 

The basic steps in supportability trend analysis are: 

1. Analyze the operations and support systems to identify 
items that could lead to a system failure, schedule 
delay, or cost increase if support degrades. 

2. List these items as candidates for supportability trend 
analysis. 

3. Select items from the list of possible candidates. 
Provide the list of items to the Program/ Project 
Office. 

4. Determine the parameters to be used in judging whether 
the item's supportability is fluctuating at a rate 
sufficient to warrant management attention. When these 
parameters are critical to safety or mission success, 
strong consideration should be given to the feasibility 
of performing trend analysis. 

5. Determine if measurement data are available for the 
selected supportability parameters. Supportability 
parameters may be directly measurable factors or the 
relationships between two or more parameters based on 
an algorithm. If measurement data are not available, 
determine the feasibility of establishing a system to 
measure the parameters. 

6. Establish the supportability baselines and limits. 
Original baselines and limits should be taken directly 
from program/project support requirements. The 
following documents are examples of the type of sources 
that should be reviewed to determine what values 
represent acceptable supportability for each indicator: 

a. OMRSD 

b. Logistics Support Plans 

c. Design Criteria 

d. Program Requirements Documents 

e. Specifications 
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f. Intermediate and Depot Maintenance Requirements 
Documents (IDMRDs) . 

Determine the measurements necessary to evaluate the 
chosen parameters. 

8. Collect/measure/ record the data and perform a 
supportability trend analysis to determine if the 
parameter being trended exceeds the historical limits 
or falls below the supportability baseline. If so, 
immediate management attention may be needed to correct 
the situation. If the values are within limits but the 
trend indicates that they may exceed the limits in the 
future, this early warning allows management to 
implement preventive measures before the situation 
deteriorates. 

9. Report the results using charts, graphs, and 
recommendations . 


C700 REPORTING 
C701 FORMAT 

1. To the extent practical, trend analysis techniques and 
formats should be standardized based on NASA-STD- 
8070.5, "Trend Analysis Techniques." 

2. The supportability element chart should depict an 
historical trend of substantiated data on the 
characteristic being measured with realistic program/ 
project control limits for that subsystem or repair 
location. When an adverse trend has been identified or 
a control limit has been (or is expected to be) 
exceeded, a detailed analysis should be provided, 
including a discussion of what corrective action, if 
any, is required. 


C702 BASIC SUPPORTABILITY ANALYSE8 

The following paragraphs provide examples of common 
supportability trend analysis reports that are used. These 
examples are not the only forms of supportability trend 
analysis that can be performed and reported. For 
simplicity, months are used to exemplify time periods and 
missions to exemplify events. Where reusable vehicles are 
involved (the Space Shuttle Orbiter, for example) , vehicle 
differences may require analyses by vehicle as well overall 
analyses by vehicle type. 


1. LRU/Spares/Line Item Demands Filled Per Month/Mission/ 
Vehicle . This report analyzes the number of demands 
that were filled for LRUs/spares or line items, 
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generated by planned and unplanned work requirements. 
Analyses of line items must clarify whether or not the 
numbers reflect the quantities of each line item. The 
subject is discussed in Section 503 (refer to Figure 
C-l) . 


STOCK DEMANDS VS. FILLS (PROVISIONED) 
FLIGHT SPARES 



Figure C-l 

2- LRU/8par es/Line Item Demand Pill Rata Per 

Month/Mission . The previous report is useful for 
inventory management; this report is most useful as a 
measure of effectiveness for the supply support system. 
This report displays the data from the previous report 
on a percentage scale on the ordinate (y axis) and time 
or event/mission sequence on the abscissa (x axis) . By 
measuring the percentage of the demands actually 
fill®*!, this report shows the ability of the support 
system to meet the demand for replacement items. 
Normally, a supply support system cannot meet all 
demands; therefore, a program/project goal or limit is 
set, based on a trade-off of cost and availability. 

This analysis shows supportability of the supply system 
relative to the program/project goal. As a form of 
supportability trend analysis, this report can be used 
to anticipate when a supply support system should 
degrade below the acceptable Probability of Sufficiency 
(POS) factors specified in program/project documents 
(refer to Figure C-2) . 
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FLIGHT SPARES FILL RATE (PROVISIONED) 
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Figure C-2 

3. z*rc Balance . This report provides the trend of out- 
of-stock line items (zero balance) in the spares/ supply 
inventory of provisioned items (refer to Figure C-3) . 
Historical and projected trends are included. 
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Figure C-3 
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The total number and individual part numbers may be 
detailed by Criticality codes such as 1/1R/1S. 

4. Expedite Actions Per Month . An expedite request must 
be filled within 24 hours. This report shows the 
expedite supply actions by month for the past year, and 
highlights the top 10 expedite requests (whether filled 
or not) , including those replaced by cannibalization 
action or withdrawn when they were not filled. 

Specific items that required two or more expedite 
actions during the past year often are reported (refer 
to Figure 04 . ) 


ET SUPPORT ABILITY TRENDS 
EXPEDITES/MONTH 
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Figure C-4 

5. Numbeg of items Cannibalized Per Month/Mission . This 
report provides a history of the number of cannibalized 
items by month and mission/ event with projected trends. 
This information is presented in a line graph report 
with detailed part number listings as background data 
(refer to Figure C-5) . 

6. Maintenance Tasks p»r Month/Ml as ion . This report 
details the total number of scheduled/unscheduled 
maintenance tasks and modification tasks completed per 
month/mission (refer to Figure C-6) . 


7. Maintenance Tasks Completed/Deferred/Waived . This 
report supplements the previous one by comparing 
completed tasks with the deferred and waived tasks. 
The breakout of tasks shows capability of the support 
program to maintain a repetitive operation. As an 
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Figure C-6 

example, if the overall number of completed tasks tend 
to remain level while the number of deferred tasks 
increases, program management has an indication that 
the support system does not have the required capacity. 
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The shortfall is being accommodated by the increasing 
number of deferrals (refer to Figure C-7) . 


MAINTENANCE STATUS 

COMPLETED/WAIVERED/DEFERRED 


Maintenance Tasks 
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Figure C-7 

7. OMR8D Requirement Changes Per Month/Miasion . This 
report shows the number of OMRSD changes per 
month/mission. It delineates the number of changes 
submitted versus approved for each major element (such 
as Work Package, major system, power system, Orb iter, 
ET, SSME, etc.)* This report also can show the number 
of waivers and exceptions by month/mission, and the 
number of new requests (refer to Figure C-8) . 

8. crew Maintenance Time Per Month/Mission - This report 
shows the total n umb er of man-hours expended per month 
for on-orbit maintenance by the crew and the average 
number of hours per individual actually performing 
maintenance tasks. Control limits on crew time for 
space flight system maintenance are specified in the 
program/project function and resource allocation 
requirements. For launch-and-return missions, the 
maintenance should be normalized as maintenance time 
per flight hour (refer to Figure C-9) . 
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Figure C-8 


CREW MAINTENANCE 

MAINTENANCE HOURS PER FLIGHT/ORBIT HOUR 
o.oe 

0.06 

0.04 

0.02 

0 

TAT Per Repair Agency Per Month . This report shows the 
status and trends of the repair TAT by agency per month 
(refer to Figure C-10) . 
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TREND OF REPAIR TURNAROUND TIME (RTAT) 



Figure C-10 

M»int«aaiic« Action BV Causes P»r Mo ntfr/MlPglQ a- This 
report illustrates the breakout of support problem 
causes. It shows if any cause has an unfavorable trend 
in comparison to other causes (refer to Figure O ) 


MAINTENANCE CAUSE ANALYSIS 

TOP 15 CAUSES - PREVIOUS 10 MISSIONS 

300 
250 
200 
150 
100 
50 
0 

CODES USTED N NASA 1234 56A 

Figure C-ll 



015 




C703 FREQUENCY 


1. The data analyses, trend charts, and the above reports 
should be made available to the program/project via 
regular and special reports. 

2 . Routine reporting requirements should be established by 
the program/project managers. Once established, the 
trend reports should be updated at regular intervals, 
usually monthly and/or by mission/event. When trend 
data indicate rapid change or that timely availability 
of trend analysis is required, the trend reports may be 
prepared on a more frequent basis. Copies of the trend 
reports should be made available to NASA Headquarters, 
Safety and Risk Management Division (Code QS) , and the 
cognizant Associate Administrator for the 

program/ pr o j ect . 

3. NASA management must be alerted in a timely manner of 
any supportability trend analysis results that may 
impact safety. 
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APPENDIX D 


PROGRAMMATIC TREND ANALYSIS 


D100 INTRODUCTION 

Programmatic trend analysis is a tool to assess program 
information such as schedule elements, employee utilization 
and attrition rates, overtime, noncompliance with operating 
procedures, equipment damage, mishaps/ injur ies , past program 
performance, and any similar data to identify problems in 
applying resources to comply with procedural requirements 
and manage program schedules. 


D200 OBJECTIVES 

The principal objective of this analysis is to provide a 
medium that accurately and quantitatively monitors the 
programmatic posture and provides management visibility to 
determine the current/pro jected health of the human support 
element. Other important objectives include: 

1. Increase management awareness of inappropriate demands 
on human resources (workload or schedules) required to 
support the program/project and associated hardware/ 
software . 

2. Prevent possible compromises or delays in mission 
schedules caused by dysfunctional responses by the 
human element to stress. 

3. Support management in identifying schedule, human 
resource allocation, experience or qualification 
mismatches that could have potential adverse effect on 
the program schedule or performance. This may require 
procedural, assignment, or schedule modifications to 
maintain or enhance performance. 

4. Support management in identifying areas requiring 
attention (such as damage, mishaps, or injuries rates). 
Determine the correlation with overtime or other 
potential program-related indicators. 

5. Support proposed program/project improvement changes. 

6. Support management in identifying and monitoring 
program/project Management Performance Indicators 
(MPIs) over time to assure process controls. These 
indicators directly affect the ability of an end- 
product to perform safely and reliably. 
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D300 CANDIDATES 


Programmatic data should be used to monitor and report on, 
but is not limited to, the following areas: 

1. Manpower strength by specialty, experience, 
qualification, certification, and grade. 

2. Personnel attrition/turnover rates by discipline. 

3. Schedule changes/slippage/or overages. 

4. Overtime usage versus approved policy. 

5. Incidents such as damage/ fire, mishap, or injury. 

6. Requirement changes, including waivers and deviations. 

7. System nonconformances and problems caused by human 
error. 

8. Rework expenditures. 


D400 DATA SOURCES 

1. The data sources for programmatic trend analyses are 
more varied than for any other type of trend analysis. 
In most cases, program/project offices maintain data 
bases that provide appropriate data or have the 
potential to yield MPIs with minimal modification. On 
newer programs / pro jects , integrated data systems such 
as the Space Station Freedom Program Technical and 
Management Information System (TMIS) have been created 
to increase access to, and speed analysis of, program 
data. 

2. Excellent data sources for programmatic trend analysis 
may be found in: 

a. Budget planning and expenditure reports 

b. Program/project schedules 

c. Quality assurance records 

d. Test and development status reports 

e. Inventory records 

f. Equipment problem reports 

g. Contractual acceptance records 

h. Shipping and receiving reports 
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i. Work authorization documents 

j . Manpower status reports 

k. Resource utilization records 

l. Safety reports 

m. Management Information Centers (MICs) . 


D500 PROCEDURES 
D501 STANDARD DATA 

1. Each program/project should compile data as described 
in Section 700 of this appendix and the referenced 
figures . 

2. Programs/projects should maintain the list of elements 
for which they will supply programmatic data; ensure 
the validity of the data provided for programmatic 
trend analyses; develop required analytical techniques 
and controls; and determine the structure for project 
data collection, maintenance, and reporting. 

3. Data should be made available to program management, 
either displayed on a separate chart for each 
programmatic indicator selected for trend analysis or 
in aggregate data reports. If work unit codes are 
defined for the program, they may be used to identify 
or reference subsystems in an element. 

4. Each chart should display an historical trend of 
substantiated data on the programmatic indicator (s) 
being measured along with the realistic control limits 
established for that indicator by the responsible 
program/project. When an adverse trend has been 
identified (whether apparent or not from the summary 
trend information) or a control limit has been exceeded 
as a result of a trend, an analysis of that trend 
should be conducted. 

5. Each program/project should accumulate data on 
programmatic indicators through completion and 
closeout . 


D502 PARAMETERS 

Suggested programmatic trend analysis indicators are 
contained in Section 701 of this appendix; however, programs 
may use other indicators. The appropriate program/project 
should define the indicator (s) to be used. Parametric 
limits may be set by policy, work standards, or directives. 


D— 3 



D600 REPORTING 


D601 FORMAT 

1. Programmatic trend analysis should be prepared with 
sufficient detail to assist management in identifying 
problems and taking appropriate action. The minimum 
content and format for the reports are defined in this 
section. Reporting should highlight high risk and 
problem areas to aid in identifying needed improvements 
and program progress/health. 

2. To the extent practical, techniques and formats for 
programmatic trend analysis should be standardized 
based on NASA-STD-8070 . 5 , "Trend Analysis Techniques." 

3. The following list of suggested programmatic trend 
analysis indicators may be expanded/modified as the 
program/project and programmatic trend analysis 
matures. Other indicators may be tracked and 
maintained by the programs /projects at their 
discretion. 

a. Manpower Strength . The number of personnel 

assigned to the program/project should be reported 
each month (Figure D-l) through the program 
management information system (MIS) . A history of 
the number of personnel assigned to each program 
should be included in a graphical report of overall 
personnel totals by month. Additional charts 
(Figure D-2) should show personnel totals by 
discipline and by percent change of individuals. 
Trends of changes in personnel assigned by total 
and by disciplines should be compared with an 
overall average change rate to determine if unusual 
turnover is reflected. At least 12 months should 
be reflected in each monthly report. 
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Figure D-l 


PROGRAM MANPOWER BY DISCIPLINES 
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Figure D-2 

b. Schedule Changes Per Month . This report (Figure 
D-3) should detail the schedule deviations per 
month for the past 12 months, including total 
number of schedule deviations and the average 
amount of monthly deviation. When a schedule for a 
particular activity or milestone is changed two or 
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more times, the affected activity should be 
highlighted and explained in the monthly report 

MONTHLY SCHEDULE CHANGES 

TEST AND EVALUATION 
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Figure D-3 

overtime Usage Par Month . This report (Figure D-4) 
should track the total amount of overtime beyond a 
40-hour work week. 


MONTHLY OVERTIME 

PERCENTAGE OF TOTAL WORK TIME 


MAY JUN M 


Figure D-4 
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d. 


Incidents Per Month . This report (Figure D-5) 
should include the incidents per month for the 
preceding 12 months. The major elements of this 
report should be: damage, injuries, and major 
mishaps per A/B/C category. Graphs should be 
presented to display the number of incidents and 
cost of each category, where applicable. 
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PHASE B 
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Figure D-5 

e. Requirement Changes Per Month . This report should 
show the number of changes to the top-level 
operational and maintenance requirements document 
per month for the last 12 months (Figure D-6) . It 
should delineate the number submitted versus the 
number approved, by major element. Waivers and 
exceptions, and the number of new requests, should 
be shown by month (Figure D-7) . 


D602 FREQUENCY 

Frequency of programmatic trend analysis should be specified 
by the cognizant program/project office. 
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Figure D-6 
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Figure D-7 
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APPENDIX E 


GLOSSARY OF TERMS 


The following terms apply to this Handbook: 

Abscissa 

X coordinates in a rectangular coordinate system. 

Cannibalization 

The removal of a serviceable (i.e., flight certifiable) item 
installed in the system element or critical GSE end item to 
replace an identical unserviceable or missing item in the 
system when spare availability does not meet demand. 

Certification 

Documentation stating that personnel, facilities, tools, or 
test eguipment meet prescribed program standards. 

Contamination 

Any effect arising from the induced environment gaseous, 
particulate, or radiation background that interferes with or 
degrades hardware such that refurbishment is required before 
continued use. 

Correction Factors 

Mathematical constant or variable factors that remove the 
effects of known biases, errors, and irrelevant variables 
from the data under analysis. Normalization is one form of 
correction . 

Corrective Action 

Action to eliminate a problem cause that includes one or 
more of the following dispositions: 

a. Design change 

b. Manufacturing method/procedures/process change 

c. Test procedure change 

d. Facility/test equipment change 

e. Transportation or shipping change 

f. Maintenance procedure change 

g. Training or certification of personnel 

h. Limited time or cycle of component. 

Correlation 

A measure of the accuracy of a trend model to represent 
actual data and predict future values. 

Critical Item 

A system/subsystem with a FMEA criticality of 1, IS, 2 (with 
a single point failure), or 1R (if it fails redundancy 
screens) . 


E-l 



Critical Items List (CIL) 

An FMEA-derived list (published as FMEA/CIL) containing 
system items that have a criticality of 1 or 2 , and items 
that are criticality 1R or 2R and fail redundancy screens. 

Critical Item Risk Assessment (CIRA) 

An evaluation of critical items that combines FMEAs with the 
associated probabilities of failure. 


Critical Software 

Software that exercises or protects critical hardware, 
performs a critical function within specified limits and 
under specified conditions. (Includes software that 
performs OMRSD logic sequencing.) 


Criticality Categories 

A criticality category classification is assigned to every 
identified failure mode for each item analyzed for all 
mission phases. Criticality categories are assigned to 
provide a qualitative measure of the worst case potential 
consequences resulting from item failure. The criticality 
categories are defined as follows: 


Category 

1 


1R 


IS 


1SR 


2 


2R 


3 


Potential Effect 


Single failure that results in loss of human 
life, serious injury to flight or ground 
personnel, or loss of a major space mission 
resource (e.g., shuttle, space station, or space 
telescope) . 

Failure modes of like or unlike redundant items 
all of which, if failed, could lead to 
Criticality Category 1 consequences. 

Single failure in a safety or hazard monitoring 
system that causes the system to fail to detect 
or operate when needed during the existence of a 
hazardous condition and lead to Criticality 
Category 1 consequences. 

Failure modes of like or unlike redundant items 
in a safety or hazard monitoring system, all of 
which, if failed, could lead to Criticality 
Category IS consequences. 

Single failure that results in loss of one or 
more essential mission objectives as defined by 
the program office without resulting in 
Criticality Category 1 consequences. 

Failure modes of like or unlike redundant items 
all of which, if failed, could lead to 
Criticality Category 2 consequences. 

All other failure modes. 
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Depot Level Maintenance 

Maintenance that is performed by designated maintenance 
sources. It normally consists of maintenance that requires 
GSE, facilities, or skills that are not economically 
available at the intermediate level, (i.e., repairing, 
overhauling, reclaiming or rebuilding parts, assemblies, 
subassemblies, components and end items, manufacturing of 
unavailable parts, and providing technical assistance to the 
organizational and intermediate levels) . 

End Item 

A system, subsystem, or major item that is capable of 
performing its intended function unaided except for 
expendable support, (i.e., fuel, electrical power, gases, 
connecting hardware, etc.). 

Engineering Change Proposal (ECP) 

A proposed engineering change to modify, add to, delete, or 
replace parts in an end item. The term ECP is commonly used 
to refer to the change after the proposal is approved. 

Expedite Action 

The need for a spare, repair part, or other supply 
requirement within a 24-hour time period. This requirement 
will have been approved by an appropriate level of 
management . 

External Tank (ET) 

The expendable element of the Space Shuttle that contains 
the fuel and oxidizer for the SSMEs. The ET separates from 
the Orbiter shortly before orbit is achieved, and 
disintegrates upon reentry into the Earth's atmosphere. 

Failure 

The inability of a system, subsystem, component, or part to 
perform its required function within specified limits, under 
specified conditions, and for a specified duration. 

Failure Mode and Effect Analysis (FMEA) 

Analysis to determine the possible modes of failure and 
resulting effects. 

Functions 

The normal or characteristic actions of an item, sometimes 
defined in terms of performance capabilities. 

Goodness-of-f it 

See Correlation. 

Institutional Support Facilities 

Facilities that support flight operations or research 
programs/projects, but are the direct responsibility of NASA 
field activities. 
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Integrated Problem Assessment System (IPAS) 

The problem assessment portion of PCASS where problem report 
data are stored. 

Intermediate Level Maintenance 

Maintenance that is performed in direct support of 
organizational level maintenance and involves disposition, 
repair, service, modification, calibration, and verification 
of items removed during organization maintenance. 

Launch Commit Criteria (LCC) 

Specific performance criteria that must be met to permit 
launch of a system. 

Line Replaceable Unit (LRU) 

Any item, the replacement of which constitutes the normally 
accepted organizational maintenance repair action for a 
higher indentured item. 

Logistics 

The branch of engineering concerned with maintaining 
operational capability throughout the life cycle of a 
system. 

Maintenance 

Consists of the actions taken to retain an item in a 
specified condition by providing systematic inspecting, 
detecting, and servicing for the prevention and correction 
of a specified operational condition. This includes fault 
isolation, item replacement, repair, and verification of 
serviceability. 

Management Information Center (MIC) 

A center of information/analysis that is readily available 
to support management functions. 


Mean 

The term used to describe a sample population average. 

Mean Time to Repair (MTTR) 

The average elapsed corrective maintenance time (hours or 
days) between system, subsystem, or LRU failure and 
restoration of that system, subsystem, or LRU to an 
operational state. 

Mission 51L 

Space Shuttle Mission 51L, the twenty-fifth Space Shuttle 
mission (tenth flight of the Orbiter Challenger) which 
experienced catastrophic inflight failure on January 28, 
1986. 

Nonconformance 

A condition of any article of material in which one or more 
characteristics do not conform to requirements; see Failure. 
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Nonconforming Article (NCA) 

The system/ subsystem/part that does not conform to 
requirements . 

Normalization 

The process of correcting raw data to remove the effects of 
nonrelevent variables and allow the data to be compared in 
"normal" conditions. Compare with correction factors. 

Nyquist Sampling Theorem 

A mathematical theorem that proves that digital sampling 
must be performed at twice the highest analog signal 
frequency/ rate to be capable of correctly representing the 
analog signal. 

Nyquist Rate 

The minimum digital sampling rate that can accurately 
represent an analog signal. 

Off-Line Maintenance 

That maintenance performed at the intermediate or depot 
levels . 

On-Line Maintenance 

That maintenance function performed at the organizational 
level . 

Operations and Maintenance Requirements and Specifications 
Document (OMRSD) 

Documents containing preflight maintenance, servicing, 
inspection, time/age/cycle, and checkout requirements for a 
flight vehicle or ground-based system. 

Orbital Replaceable Unit (ORU) 

The lowest level of component or subsystem hardware that can 
be replaced in orbit. 

Orbiter 

The reusable space plane element of the Space Shuttle that 
contains the crew compartment/ systems and payload bay. 

Ordinate 

Y coordinates in a rectangular coordinate system. 

Organizational Level Maintenance 

Maintenance performed on subsystems and related support 
equipment in direct support of mission activity. It 
includes scheduled and unscheduled maintenance actions 
required to inspect, service, calibrate, replace, repair, 
and modify in place, and reverify subsystems and associated 
components . 

Parameters 

The term applied to population or sample characteristics 
such as the mean and standard deviation. 
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Parametric limits 

Design performance limits not to be exceeded (upper and/or 
lower) . Certain design parameters may be established with 
only a single bound. 

Pareto Concept 

The concept that a relatively large percentage (80-90%) of 
problems will be caused be a relatively small percentage 
(10-20%) of related factors. 

Pareto Diagram 

A rank ordering of problem causes by their contribution, 
usually in decreasing order. 

Performance Trend Analysis 

Analysis of data based upon the measurement of specific key 
performance parameters (e.g., pressure, temperature, and 
viscosity) , which indicate the safe and effective operation 
of a critical process or item of hardware/software. 

Problem 

Any nonconformance that fits or is suspected of fitting one 
of the following categories: 

a. Failure, including conditions that would result in 
OMRSD waivers 

b. Unsatisfactory condition 

c. Unexplained anomaly 

d. Overstress or potential overstress of hardware 

e. Inflight anomaly 

f. Any nonconformance that has shown by trend analysis 
to need recurrence control. 

Problem Report (PR) 

A report of a malfunction, failure, or inadequate 
performance of a system/subsystem/component. 

Problem Reporting and Corrective Action System (PRACA) 

A system (usually automated) to record, monitor, and analyze 
problems and their associated corrective actions. 

Problem Trend Analysis 

Analysis of data based upon the number of problems occurring 
in the area under study (e.g., number of problem reports 
associated with solar panels) . Its purpose is to identify 
the source of key problems and to track whether action taken 
to resolve the problem is effective. 

Program Compliance , Assurance, and Status System (PCASS) 

An automated system to compile data from various system and 
elements to provide program managers with critical 
information. Common PCASS data include requirements status, 
problem data, risk decisions, trend analyses, hazards, 
critical item history, and FMEA/CIL information. 
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Programmatic Trend Analysis 

Analysis of institutional information relating to program 
schedule and to supporting personnel activities (e.g., 
employee utilization, worker attrition rates, overtime, and 
noncompliance with operating procedures) . These analyses 
are used to assess the impact of schedule pressures and 
major disruption in resource capability or the ability of 
the work force (or human factor) to respond in a predictably 
safe and reliable manner. 

R-square (R 2 ) 

A quantitative measure of the correlation or goodness-of-f it 
of a trend model to actual data. 

Reliability 

The probability that an item will perform its intended 
function adequately, without failure, for a specific time 
period under specified conditions. 

Reliability Data 

All the failure data, inspection findings, and other 
information derived from the actual service history of each 
item. 

Repair Turnaround Time ( RTAT ) 

The period between the time an item is removed from the 
system for off-line repair and the time that it is returned 
in ready-f or-installation condition. RTAT includes the time 
an item is waiting for available shop time, diagnosis, 
parts, hands-on work, test, and final inspection. 

Safety, Reliability, Maintainability, and Quality Assurance 
(SRM&QA) 

The disciplines of assurance engineering that are concerned 
with the assurance of mission success with minimized risk. 
SRM&QA commonly is used to refer to those organizations that 
are collectively concerned with assurance engineering. 

Sample Size 

The number of items selected from a population that will be 
used to make inferences about the total population. 

Scheduled Maintenance 

Preventive-maintenance tasks scheduled to be accomplished at 
specified intervals. 

Shop Replaceable Unit (SRU) 

Any item whose replacement constitutes the optimum 
intermediate or depot level of repair actions for a higher 
indentured item. 

Significant Problem 

Any problem that is considered to pose a serious risk to 
safety or mission accomplishment (schedule and objectives) . 
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Significant Problem Report (SPR) 

A means of communicating significant technical problems and 
anomalous conditions having an impact on safety or mission 
success upwards through management levels. 


slope 

The rate of change in Y per unit change in X for a line 
plotted in the X-Y coordinate system. 

Solid Rocket Booster (SRB) 

The element of the Space Shuttle that consists of the two 
solid rockets attached to the sides of the ET to augment 
ascent thrust at launch. They are separated soon after 
lift-off and recovered for reuse. 

Solid Rocket Motor (SRM) 

The nozzle and control systems of the SRB that provides 
vectored thrust from the burning of the solid fuel. 

Space Shuttle 

The manned orbital launching system that is comprised of an 
Orbiter spacecraft, Space Shuttle Main Engines, External 
Tank, and Solid Rocket Boosters. 

Space Station 

A permanent orbital complex comprised of manned, man-tended, 
and unmanned orbital platforms. 

Space Station Freedom 

The Space Station manned platform including the ESA Columbus 
Module and the Japanese Experimental Module. 

Space Shuttle Main Engine (SSME) 

The reusable liquid fuel engines that provide the main 
vectored thrust for the Space Shuttle. They are attached to 
the Orbiter element and are recovered by the reentry and 
landing of the Orbiter. 

Statistical coefficient of determination (R-Square) 

The square of the correlation coefficient. 

Supportability Trend Analysis 

Analysis of the effectiveness of logistics elements in 
supporting NASA programs/projects. Supportability trend 
analysis is concerned with the recurrence of logistics 
problems and the effective control of these problems. 

System 

A set of components and their connecting links that provide 
some basic function. 

System Automation 

The incorporation of sensors and data system capabilities 
into system and element designs to support automated system 
status monitoring, trend analysis, fault detection, 
isolation, and recovery/reconfiguration. 
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Teardown Inspection/Analysis 

Documented results of the test and disassembly of hardware 
under the direction of the responsible organization to 
determine if incipient failures may be present. 

Technical and Management Information System (TMIS) 

An advanced network of compatible hardware and integrated 
software used to provide systematic management information 
development and exchange between Space Station Freedom 
personnel . 

Time/Age/Cycle Data 

Statistical data that provides information to assure items 
are removed/replaced at the proper time of the operating 
life cycle. 

Trend Analysis 

The analysis and evaluation of an item, system or subsystem, 
or programmatic element of a program in relation to designed 
or planned quantitative and qualitative parameters based on 
actual data collection reports. 

Turnaround Time (TAT) 

The interval between the time a repairable item is removed 
from use and the time it is again available in full 
serviceable condition (see Repair Turnaround Time) . Also, 
vehicle turnaround time, relating to reusable aeronautical 
or space vehicle processing from wheel stop of one mission 
to lift-off of the next mission for the same vehicle. 

Unsatisfactory Condition Report (UCR) 

Rocketdyne Corporation terminology for a problem report. 

Variability 

A term expressing the dispersion or spread of values about a 
mean value. 

Work Package (WP) 

A complement of program activities that is assigned to a 
selected responsible NASA field installation. It describes 
the type and scope of the activity to be performed at any 
level of detail and can include development of hardware, 
software, interfaces, systems operation, and system 
utilization operations. 

Work Unit Code 

An alphanumeric characterizing indentured equipment 
identification code that uniquely identifies the entire 
system from the top down to Line or Orbital Replaceable Unit 
component use level. It functionally identifies the system, 
subsystem assembly, component, and significant repairable 
part on which maintenance is to be performed. 
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APPENDIX F 


A/D 
ATP 
CIL 
CIRA 
Code Q 
Code QS 
ECP 
ET 

FMEA 

HA 

IDMRDs 

IPAS 

LCC 

LRU 

MIC 

MIS 

MPIs 

MTBF 

MTBR 

MTTR 

NCA 

OMRSD 

ORU 

OSMA 


LIST OF ACRONYMNS 

Analog-to-digital 

Acceptance test procedure 

Critical Items List 

Critical Item Risk Assessment 

NASA Associate Administrator for the OSMA 

NASA Headquarters, Safety And Risk Management Division 

Engineering Change Proposal 

External Tank 

Failure Mode Effects Analysis 
Hazard Analysis 

Intermediate and Depot Maintenance Requirements 
Documents 

Integrated Problem Assessment System 
Launch Commit Criteria 
Line Replaceable Unit 
Management Information Center 
Management information system 
Management Performance Indicators 
Mean time between failures 
Mean time between repairs 
Mean time to repair 
Nonconforming Article 

Operations and Maintenance Requirements and 
Specifications Document 

Orbital replaceable unit 

NASA Office of Safety and Mission Assurance 
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PCASS 

POS 

PR 

PR 

PRACA 

R&D 

R-Square 

RFI 

RSRM 

RTAT 

SPR 

SRB 

SRM 

SRM&QA 

SRU 

SSME 

TAT 

TMIS 

UCR 

WP 


Program Compliance Assurance and Status System 
Probability of Sufficiency 
Problem Report 
Procurement request 

Problem Reporting and Corrective Action 
Research and development 

Statistical coefficient of determination 

Ready-for-installation 

Redesigned Solid Rocket Motor 

Repair turnaround time 

Significant Problem Report 

Solid Rocket Booster 

Solid Rocket Motor 

Safety, Reliability, Maintainability, and Quality 
Assurance 

Shop Replaceable Unit 
Space Shuttle Main Engine 
Turnaround Time 

Technical and Management Information System 
Unsatisfactory Condition Report 
Work Package 
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